A Typology of Real-Time Parallel Geoprocessing for the Sensor Web Era

1 Introduction The rise of digital sensors and the Sensor Web is expected to have wide reaching implications for the monitoring of the physical and human world [1] and has already resulted in an explosion in the volume and availability of spatially referenced data pertaining to our surroundings. While this deluge of easily accessible near real-time data brings numerous opportunities, it also presents a significant challenge in terms of geoprocessing. Existing geoprocessing systems must be adapted to meet the requirements of this new era of spatial data infrastructure. Although real-time geoprocessing systems have existed for some time in fields such as environmental monitoring, they have usually been part of a stove-piped system in which the geoprocessing component was specifically engineered for the given application [2]. In today's world of service orientation, geoprocessing components are often developed as services that can be swapped in and out of systems with ease. Web service standards defined by the Open Geospatial Consortium (OGC) have become widely adopted. The OGC Web Processing Service (WPS) defines a uniform interface to encapsulate heterogeneous geoprocessing functionality [3]; by chaining OGC data and processing services geoprocessing workflows can be rapidly composed. As a result, we have come to expect generic geoprocessing services to be available that meet our requirements. However, the requirements of real-time monitoring and prediction scenarios differ significantly from offline geoprocessing in terms of usage patterns, computational characteristics and data processing methodologies. Real-time systems must often process continuous jobs of an unknown size or duration [4]. They may be required to work to a hard real-time deadline, or to keep pace with the rate of data arrival [5]. Additionally, they must be capable of operating on data streams as well as static datasets, and in some cases to perform complex event or pattern detection [6]. Furthermore, data acquired from sensors is often unreliable so geoprocessing systems need to be robust to corrupt and missing observations [7]. For these reasons generic geoprocessing services designed for offline analysis are often unsuited to operating on near real-time sensor data.